Same as previous comment here.

Likewise, I clarified the example, let me know if it seems more appropriate now.

I'm wondering to what extent non-developer members of the QA team will be expected to fully understand the implications of major changes, particularly to the point where they're expected to help review PRs. Is it more a case of the QA team ensuring that tests exist or at least a testing strategy exists for verifying changes in PRs rather than the entire substance of the change?

Thanks, this point is important to discuss as test coverage can be a bit subjective and the inability to fully understand the changes could result in QA approving coverage of a feature that isn't properly tested. My initial reaction is that the QA team is there to stand up processes, protocols and tools and ensure that they are properly used by contributors. As indicated, development knowledge is required to assess whether the test coverage is accurate (not to mention long term implications arising from the relevant changes that are not realizable with testing frameworks alone).

We may decide that it is sufficient for a QA team to ensure that changes are trivially covered by the testing framework and that other tests don't fail. We may decide that there is no point in a QA team if it cannot make a more meaningful assessment than a binary test pass/fail, covered/not. It could be helpful to distinguish what is required for a minimally viable QA team that adds tangible value and what is required for an ideal high-performing QA team.

This part of it is key to me. In my mind an effective QA takes a very active role in the creation of tools, frameworks and environments that continually deploy and test changes. Of course this can be supported by developers, but the QA team very much needs to drive the overall testing vision and take the leadership to ensure the correct tools are in place.

I think it would be reasonable to expect the QA team to develop and make available the tools for sufficient testing. This looks like a big initial effort to get a test harness to support the node, wallet and miner. Additionally if new aspects emerge that require integration, an initial effort may be required to glue the necessary pieces so that contributors can begin adding and testing those as well. Beyond those initial efforts to add support to unsupported areas, as currently written, any changes should really be the responsibility of contributors.

However if the QA team doesn't give contributors everything possible to succeed (good documentation, sane frameworks, stationary goalposts etc.) then the responsibility comes back to the QA team in my opinion. There's probably room for a lot of discussion and clarification here. For an ideal QA team, technical vision and leadership is essential. Whether this is necessary for a minimally viable QA team seems open (as is the question of whether a minimally viable QA team is worth it).

This seems a little bit at odds with what's stated above about what the responsibilities do not include... for instance, surely the QA team will want to ensure their tooling and testing frameworks are up to date? Perhaps they won't be expected to maintain them 100% themselves, but the team would be the one striving to ensure they're in place, up-to-date and effective

As it is currently written, my understanding is that the QA team is responsible for ensuring the tooling and frameworks are working before a contributor starts (this should be a function of the initial setup and ensuring that contributors don't make changes without adding working test coverage).

The distinction is that the QA team is not responsible for updating the test framework to cover a change made by a contributor- the QA team is responsible for making sure that the contributor updates the test framework to cover their own change. This is supported by the QA team ensuring that expectations are documented, that the initial framework was set up properly and that changes from there were covered by their contributors.